Hi, thank you for the great tool.

Summary

Fix code generation crash when multiple value descriptions share the same label but map to different raw values.

Background

Some DBC files define distinct raw values using the same textual description:


VAL_ 1042 LANE_SWAY_WARNING 3 "ok" 2 "orange ..." 1 "prompt ..." 0 "ok";


The generated Go constants would then collide:


const (
    LANE_SWAY_WARNING_ok = 0
    ...
    LANE_SWAY_WARNING_ok = 3 // duplicate identifier -> compile error
)

Fix

In SignalCustomType constant generation:

• Track constant names used within the enum.
• On name collision, append the numeric value: _.
• If that still collides (pathological), append a suffix counter: .
• If a name is unique, it remains unchanged.

This preserves stable names where possible and only adjusts those that previously failed to compile.

Resulting behavior

• Previously valid schemas: unchanged constant names (non-breaking).
• Previously failing schemas (duplicate labels): now compile with disambiguated names.

Examples

Input DBC:


VAL_ 1042 LANE_SWAY_WARNING 3 "ok" 2 "orange ..." 1 "prompt ..." 0 "ok";


Before (error):


const (
    LANE_SWAY_WARNING_ok = 0
    LANE_SWAY_WARNING_orange = 2
    LANE_SWAY_WARNING_prompt = 1
    LANE_SWAY_WARNING_ok = 3 // duplicate identifier
)


After (compiles):


const (
    LANE_SWAY_WARNING_ok = 0
    LANE_SWAY_WARNING_orange = 2
    LANE_SWAY_WARNING_prompt = 1
    LANE_SWAY_WARNING_ok_3 = 3
)


Pathological example (three “ok” entries: 0, 3, 5):


const (
    X_ok = 0
    X_ok_3 = 3
    X_ok_5 = 5
    // If a collision somehow still occurs, it becomes X_ok_5_2, etc.
)

Notes

• Adds a small, local name de-duplication map per signal type.
• No behavior changes for distinct labels; only duplicate-label cases are affected.